At present, with the development of computer multi-core technologies, a multi-thread program is applied more and more extensively. There are two major problems with the multi-thread environment: one is resource sharing, namely, a plurality of threads share a physical memory of the same entity; the other is resource synchronization, namely, the multi-thread environment requires the physical memory of the same entity to be accessed by only one thread at the same time. As can be seen from the above, resource sharing and resource synchronization are two requirements which are contradictory to each other. On the premise of ensuring the resource sharing, when the plurality of threads simultaneously request for allocation of the global heap, “lock contention” will occur That is to say, a thread requesting later must wait for being unlocked until the shared memory allocation is completed by a thread that requests earlier, thereby performing memory allocation. If the number of the threads simultaneously requesting for memory allocation is too large, the running speed of the program will drop, thereby causing phenomena such as “breakdown” or even “system crash.” FIG. 2A illustrates one example of this situation. As illustrated in FIG. 2A, the threads 1-N need to share the global memory heap. As required by resource synchronization, allocation of the global memory heap can be carried out for only one thread at the same time, and other threads must be in a locked state waiting for synchronization of the memory resource.
There is a technical solution to the above problem in the prior art, as illustrated in FIG. 2B, the shared global memory heap in FIG. 2A is divided into a plurality of sub-heaps Heap1-HeapN, and several threads are allocated for each sub-heap. The technical solution indeed can ease the lock contention to a certain degree, but each of the sub-heaps is allocated with several threads, so the lock contention issue still exists. More importantly, upon division of sub-heaps and allocation of threads, it is impossible to know which threads should be allocated to which sub-heaps so as to achieve the best running effect. Hence, it often occurs that the sub-heap Heap 1 is in an idle state whereas the sub-heap Heap 2 is already in a lock contention state, thereby causing a waste of the memory resource and a lot of memory fragments.